fix(artists): cache popular-artists fallback in Redis (suggestions empty bug) - #707

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/backend/src/routes/artists.ts`:
- Around line 126-132: The Redis-cached payload read via
redisClient.get(FALLBACK_SUGGESTIONS_CACHE_KEY) is used without validating its
shape, so a non-array or malformed JSON will cause fallback.length/iteration
errors; update the try blocks around redisClient.get(...) (and the similar code
near lines handling the same key) to JSON.parse the cached value then verify
it's an array of SpotifyArtist-like objects (e.g., Array.isArray(parsed) and
optional checks for expected fields) before assigning to the fallback variable;
if validation fails, ignore the cache (leave fallback as the live-fetch
sentinel) and proceed to fetch from Spotify to prevent 500s.
- Around line 137-181: The fallback-population code currently lets concurrent
requests run the 12-query loop and can cache partial results; fix by using a
Redis single-flight lock via redisClient.setNxPx() on
FALLBACK_SUGGESTIONS_CACHE_KEY (or a derived lock key) before running the
suggestQueries loop so only one process populates at a time, have other callers
detect the lock (read the cache in a short retry/backoff loop and return cached
value if populated), and only call redisClient.setex to cache results if
fallback.length meets a minimum threshold (e.g., >= 24 or a configurable
populationThreshold); always release the lock (delete the lock key) in a finally
block and on failures avoid caching partial results or use a much shorter TTL
variable instead of FALLBACK_SUGGESTIONS_TTL_SECONDS.